Implementing changes for hardware, software, network and storage systems in large-scale eBusiness environments remains painful to customers: Rolling out changes, such as (un)installing, upgrading or configuring systems can take weeks, partly because the complex interdependencies between applications and their supporting services are not made explicit, thus requiring human involvement and expertise. Solving this change management problem automatically is important to address the increasing complexity of computing systems. The number of relationships of a single managed resource (a software artifact, a network component, a storage system) range from 10 to 100; the number of managed resource instance relationships in large-scale enterprise systems is often between 1,000,000 and 1,000,000,000. Given that a change to one or more managed resources may entail additional changes on a multitude of other managed resources, it is evident that the need for human involvement in the change management process needs to be minimized. This motivates the need for a generic approach that discovers allowable sequences of changes by interacting with the target systems.
The identification and tracking of relationships between the components of distributed systems is becoming increasingly important for change management. Software artifacts and their components rely on a variety of supporting artifacts. Consequently, applying a change to one artifact affects other artifacts, i.e., artifacts have dependencies on other artifacts. They exist between the components of different artifacts on a single system and also between the artifacts on multiple systems and organizational domains. Artifacts that depend on others are referred to as dependents, while artifacts on which other artifacts depend are referred to as antecedents. It is important to note that an artifact often plays both roles (e.g., a name service is required by many applications and services but is depending itself on the proper functioning of other services, such as the operating system and the network protocols and infrastructure), thus leading to a dependency hierarchy that can be modeled as a directed acyclic graph (DAG). Furthermore, dependency relationships are transitive, i.e., the dependent of a given component requires, in addition to the component itself, also the components' antecedent(s). Dependencies exist between various artifacts of a distributed system, such as end-user services, system services, applications and their logical and physical components.
Prior art in the area of software development [U.S. Pat. No. 4,751,635], [U.S. Pat. No. 5,960,196] and maintenance [U.S. Pat. No. 5,493,682] deals with individual software elements and modules that form the atomic parts of a program package and require the availability of program source code in order to build software and bundle it into software products. Source code is available to the software developer and not to the service user.
Prior art in the area of software packaging [U.S. Pat. No. 5,835,777] deals with individual software elements and modules that form the atomic parts of a program package and require the availability of program source code in order to build software and bundle it into software products.
[IEEE 1387.2 1995] addresses software distribution/deployment/installation. It defines a mechanism for ensuring that new software components (which are going to be installed) do not conflict with an already existing software installation. It identifies three kinds of relationships prerequisite, exrequisite, corequisite that facilitate such compatibility checks. This is done individually for every system on which new software needs to be installed. The software inventories present on other systems are not taken into account. Furthermore, this IEEE specification does not deal with instantiated applications and services and therefore does not represent any means of determining the dependencies between components at runtime.
[OpenGroup 1998] extends [IEEE 1387.2 1995] by defining several commands (swinstall, swlist, swmodify, etc.) that are invoked by software installation tools on a specific system. It also defines a software definition file format to make sure that the information required by the aforementioned commands is available from the system on which the commands are invoked. The shortcomings of [IEEE 1387.2 1995] (confined to a single isolated system, with no means for determining software dependencies at runtime) also apply to this specification.
Current Operating System Inventory implementations (such as the IBM AIX Object Data Manager (ODM), the LINUX RED HAT Package Manager (RPM) or the MICROSOFT WINDOWS Registry) follow either [OpenGroup 1998] and [IEEE 1387.2 1995] or describe the software inventory in a proprietary format. Thus, the aforementioned limitations also apply to them.
Techniques for electronic software distribution of whole program packages [U.S. Pat. No. 6,009,525] [U.S. Pat. No. 5,721,824] or updates/corrections/fixes/patches [U.S. Pat. No. 5,999,740] [U.S. Pat. No. 5,805,891] [U.S. Pat. No. 5,953,533] are, by definition, restricted to the distribution/deployment/installation of (one or many at a time) physical software packages and do not take the runtime stages of applications into account. In addition, they deal with one system at a time and do not take the cross-system aspects of applications and services into account.
Techniques for determining conflicts in existing software/hardware configurations [U.S. Pat. No. 5,867,714] are also confined to a single system and do not take runtime aspects into account.
There thus exists a need to describe a generic approach to discover allowable sequences of changes of artifacts, which prior art (such as the U.S. patent application Ser. No. 09/755,786, filed on Jan. 5, 2001, and entitled “Systems and Methods for Service—and Rolebased Software Distribution”) does not take into account. There is also a further need to determine dependency relationships in distributed systems (as disclosed in U.S. patent application Ser. No. 10/241,162, filed on Sep. 11, 2002, and entitled “Methods and Apparatus for Managing Dependencies in Distributed Systems”), and transforms such acquired relationships into task sequences that are linked by temporal ordering constraints. Examples of such constraints are: “Task X must finish before task Y can begin, Task X cannot start until task Y does, Task X cannot finish before task Y does, Task X cannot finish until task Y starts”. These constraints apply to various types of change tasks, such as install, uninstall, configure, start, stop.